System-on-chip with master/slave debug interface

ABSTRACT

A System-on-Chip (SOC) debugging system comprising a plurality of SOCs connected to a shared bus, at least one of the plurality of SOCs being a master SOC and comprising a master/slave debug interface, wherein the master/slave debug interface is a bidirectional debug interface configured to initiate transactions on the shared bus and operable to send and receive debug data between the SOCs, wherein the debug data comprises trace data.

RELATED APPLICATION

This is a reissue application of U.S. applicaton Ser. No. 13/528,140filed on Jun. 20, 2012, now U.S. Pat. No. 8,347,158, which is acontinuation application of U.S. application Ser. No. 12/913,236 filedon Oct. 27, 2012, Oct. 27, 2010, now U.S. Pat. No. 8,234,531, which is acontinuation application of U.S. application Ser. No. 11/954,362 filedon Dec. 12, 2007, now U.S. Pat. No. 7,870,455.

More than one reissue application has been filed for the reissue of Pat.No. 8,347,158. The reissue applications are the present application andapplication Ser. No. 15/136,065, filed Apr. 22, 2016.

FIELD OF THE DESCRIPTION

The present description relates generally to data processing and debugsystems, and, in particular, to a System-on-Chip (SOC) configurationthat captures and transfers debug data directly from multiple systemSOCs using an on-chip Master/Slave debug interface.

BACKGROUND

System-on-Chip (SOC) technology operates and controls various types ofsystems. In general, SOC technology is the assembling of all thenecessary electronic circuits and parts for a system (such as a cellphone or digital camera) on a single integrated circuit (IC), generallyknown as a microchip. SOC devices greatly reduce the size, cost, andpower consumption of the system.

During SOC development, debuggers are connected to the debug interfaces(e.g. JTAG port) of the SOCs. To allow synchronous debugging and to saveconnector pins, all SOCs of the system typically share one debug bus(e.g. CJTAG) and one connector to the debug tool hardware for debuggingand testing procedures. Using the debug bus, the system can be debugged(control, status and trace) through a single connector.

Because of the very high degree of integration on a single IC, in manycases, the number of Input/Output (IO) signals off the SOC device arereduced. Furthermore, as chip sizes increase, the number of transistorson a chip increases much faster than the possible number of IO signalsoff the chip. In many modern chip designs the chip is said to be pad orIO limited, which means that based on the size of the chip, there isinsufficient room for all the IO signals that the designers would like,or need, to have routed off the chip. In such environments, in order tolower costs, conserve space, and provide enhanced security, SOCs andSystems in Packages (SiPs) can be configured without debug interfacesmaking testing and debugging operations problematic. In such cases,analysis is either infeasible or significant effort is needed to soldera debug connector to the board at a time when analysis is needed.

SUMMARY

A System-on-Chip (SOC) debugging system comprising a plurality of SOCsconnected to a shared bus, at least one of the plurality of SOCs being amaster SOC and comprising a master/slave debug interface, wherein themaster/slave debug interface is a bidirectional debug interfaceconfigured to initiate transactions on the shared bus and operable tosend and receive debug data between the SOCs, wherein the debug datacomprises trace data.

These and further objectives, features and advantages will become moreapparent from the following description when taken in connection withthe accompanying drawings

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary SOC IC debugging system in accordancewith a preferred embodiment; and

FIG. 2 is a flow diagram illustrating a method for debugging multipleSOC ICs through a user interface of a master SOC IC in accordance with apreferred embodiment.

DETAILED DESCRIPTION

FIGS. 1 and 2, discussed below, are by way of illustration only andshould not be construed in any way to limit the scope of the claims.While described with respect to SOCs, those of skill in the art willunderstand that the principles may be implemented in any suitablyarranged IC or system-in-package device.

Well-known circuits have been shown in block diagram form in order notto obscure the present description in unnecessary detail. Certaindetails regarding components of the SOCs described herein have beenomitted insomuch as such details are not necessary to obtain a completeunderstanding of the present description and are within the skill of aperson of ordinary skill in the relevant art.

FIG. 1 shows a printed circuit board (PCB) system 100 for debugging,testing and monitoring the performance information of several SOCs 102,104, 106. While not explicitly shown in the figures, SOC 102 can includea processor core, a bus interface, and a system bus for communicatinginformation. SOC 102 may further incorporate a digital signal processingengine, a general purpose microprocessor to provide controlfunctionality, an on-chip memory 126 and a memory controller (not shown)for accessing memory 126. SOCs 104 and 106 may also include each of theabove elements discussed with respect to SOC 102.

SOCs 102, 104 and 106 are connected to a shared debug bus 108. PCBsystem 100 is connected to host a system 110 directly via SOC 102. Whilehost system 110 is shown independent of system 100, for purposes ofdebugging and testing a plurality of SOCs, connection with host system110 can be considered an integral part of debug system 100. The hostsystem 110 can be any type of computer (e.g., personal, mainframe, mini,networked, workstation, etc.) running host software that allows a userto target one or more components on SOCs 102, 104, 106 for debugging andto specify triggering parameters for tracing their processing cores.

SOC 102 includes a user interface 116 for connecting and communicatingwith host system 110. User interface 116 can be any type of userinterface (e.g., serial port, USB, etc.). Host system 110 communicateswith SOC 102 through user interface 116 and with the SOCs 104 and 106through debug bus 108.

SOC 102 passes debug data, such as trace data, debug control signals andstatus data, to host system 110 through user interface 116. SOCs 104 and106 to be debugged by host system 110 pass their debug data throughMaster/Slave debug interface 120 of SOC 102. Accordingly, SOC 102 takeson the role of a “Master” SOC and hereinafter will be referred to asMaster SOC 102. Likewise, SOCs 104 and 106 act as slaves to Master SOC102. The Master/Slave debug interface 120 is configured to initiatetransactions on the debug bus 108. These transactions can include, butare not limited to, instructions to store data in memory, to read datafrom memory and to transfer data to and from host system 110.

Master/Slave debug interface 120 is for instance a two-pin bidirectionaldebug interface as defined in IEEE 1149.7 (CJTAG) consisting of abi-directional Debug Data pin and a Debug Clock pin. Such an interfaceallows transferring commands to the device to control the on-chip debugsystem and to read and write data.

As mentioned briefly above, the debug data which is gathered bymonitoring one or more of SOCs 102, 104, and 106 can include trace data.A trace is useful when analyzing the behavior, or misbehavior, of an SOCor the SOCs processing core or cores. The trace can show problems in theprogramming of an SOC processing core and point to errors in the SOChardware. The trace can be thought of as an external recording of theactivity of the SOC that a user can play back with software tools on thehost system 110 in order to understand specific internal operations theSOC took and why.

The trace of external IO signals of an SOC can be augmented with otherdata to give a user additional visibility into SOCs 102, 104, 106internal operations. Bringing selected internal signals of SOCs 102,104, 106 to the outside of the system 100 as additional output signalsaccomplishes this augmentation.

System 100 includes an arbitrary number of SOCs with each SOC sharing asingle debug bus 108 (e.g. CJTAG). With SOCs 102, 104, 106 connected toone shared debug bus 108, a single SOC (i.e. SOC 102) can take the roleof a tool hardware front-end for the debug bus 108. Referring to FIG. 1,SOC 102 plays this role and hence can be referred to as “master SOC102”. On the physical level the direction of all signals is reversed forthe master SOC 102 compared to a conventional setup, where all SOCsincluding the master SOC are accessed from the debug tool over theon-board debug connector. In accordance with a preferred embodiment, thedebug interface of the master SOC 102 is operable in two differentmodes: In a default mode (e.g. reset value) it is a slave and operateslike the debug interface of any other SOC controlled from the debug toolover a hardware interface, board connector and debug bus; in the secondmode it is a master, which is enabled internally, the signal directionsare reversed (e.g. clock output instead of input) and this mastercontrols the slave debug interfaces of all other SOCs. In the latermode, a debug tool need not be attached at the debug connector on theboard.

Master SOC 102 acts as a bus bridge between the host system 110,connected over the user interface 116, and the debug bus 108. Thus, thehost system 110 accesses the SOCs 104 and 106 indirectly through MasterSOC 102, with reversed direction of its debug interface. Master SOC 102effectively replaces the need to connect conventional debug toolhardware to the PCB to carry out testing and debug procedures. Instead,Master SOC 102 is equipped with a debug monitor (not shown). The debugmonitor is preferably software running on Master SOC 102.

This debug monitor is for instance a process running on the processor ofMater SOC 102. It is activated by the operating system. When debugrequests arrive at the User Interface 116, the debug monitor analyzesthe requests, schedules transfers over the Debug Bus 108 and sends backthe results over the user interface 116. To limit the impact on thereal-time behavior of the system these tasks can be distributed overdifferent Interrupt Service Routines and real time processes. Those ofskill in the art will realize that other implementations with lesssoftware and more hardware parts of the bus bridge functionality arealso possible.

System 100 is functional without restrictions for debug control andstatus data exchange, which has low to medium latency and bandwidthrequirements. Trace data requires much higher bandwidth. If theavailable bandwidth of the user interface 116 is on average lower thanis needed for the trace data, an on-chip trace buffer (not shown) onMaster SOC 102 can be used to capture such traces from the other SOCs104 and 106 for a short period of time. If the available bandwidth ofthe user interface 116 is on average higher than needed for the tracedata, then the full trace can be output over user interface 116.

FIG. 2 shows a method of debugging system 100 of FIG. 1. The methodbegins with connecting a host system 110 to the user interface 116 ofthe master SOC 102 (step 210). Next, debug data representing theactivity of one or more SOCs 104, 106 is received by master SOC 102 viadebug bus 108 (step 220). This data can be temporarily stored by masterSOC 102 (step 230). Master SOC 102 transfers the debug data via its userinterface 116 to the host system 110 for analysis (step 240). Finally,the data is received by host system 110 where it can be analyzed by theend user (step 250).

One skilled in the art will appreciate that additional variations may bemade in the above description without departing from the spirit andscope of the description which is defined by the claims which follow.

What is claimed is:
 1. A System-on-Chip (SOC) debugging systemcomprising a plurality of SOCs connected to a shared bus, at least oneof the plurality of SOCs being a master SOC and comprising amaster/slave bidirectional debug interface operable in a first mode as aslave and in a second mode as a master, and wherein the master/slavedebug interface is a bidirectional debug interface configured toinitiate transactions on the shared bus and operable to send and receivedebug data between the SOCs, wherein the debug data comprises tracedata.
 2. The SOC debugging system of claim 1, wherein the master SOCcomprises a user interface.
 3. The SOC debugging system of claim 2,wherein the user interface is a USB interface.
 4. The SOC debuggingsystem of claim 2, wherein the user interface is a network interface. 5.The SOC debugging system of claim 2, wherein the user interface is awireless interface.
 6. The SOC debugging system of claim 1, wherein thetransactions include instructions to store data in memories of the SOCs,and to read data from the memories of the SOCs.
 7. The SOC debuggingsystem of claim 6, wherein the master SOC comprises a user interface,and the transactions further include instructions to transfer data toand from a host system via the user interface.
 8. The SOC debuggingsystem of claim 1, wherein the master/slave debug interface is a two pindebug interface including one pin for a clock signal and another pin forbidirectional data.
 9. The SOC debugging system of claim 1, wherein theat least one master SOC can be configured to function as a tool hardwarefront-end for the shared debug bus.
 10. The SOC debugging system ofclaim 1, wherein the at least one master SOC functions as a bus bridgebetween a host system and the shared debug bus.
 11. The SOC debuggingsystem of claim 1 2, wherein the at least one master SOC is connected toa host system through the user interface and accesses the non-masterSOCs indirectly through the at least one master SOC.
 12. The SOCdebugging system of claim 1, wherein the at least one master SOCincludes software acting as a debug monitor.
 13. The SOC debuggingsystem of claim 1, wherein the at least one master SOC includes a tracebuffer for capturing traces from the other SOCs.
 14. A method fordebugging a System-on-Chip (SOC) integrated circuit, the methodcomprising: transmitting debug data by a bidirectional debug interfaceof a master SOC over a shared bus between the master SOC and at leastone slave SOC; and transmitting the debug data by a user interface ofthe master SOC between the master SOC and an external system coupled tothe user interface of the master SOC, wherein the bidirectional debuginterface of the master SOC is operable in a default mode as a slavebidirectional debug interface and in a non-default mode as a masterbidirectional debug interface.
 15. The method of claim 14, wherein thebidirectional debug interface of the master SOC operates in thenon-default mode as the master bidirectional debug interface bycontrolling a slave debug interface of the at least one slave SOC. 16.The method of claim 14, wherein the bidirectional debug interface of themaster SOC operates in the default mode as the slave bidirectional debuginterface by being controlled from a debug tool located external to theSOC integrated circuit.
 17. The method of claim 14, wherein the userinterface of the master SOC is a USB interface.
 18. The method of claim14, wherein the user interface of the master SOC is a network interface.19. The method of claim 14, wherein the user interface of the master SOCis a wireless interface.
 20. The method of claim 14, further comprisinginitiating instructions on the shared bus by the bidirectional debuginterface of the master SOC to store data in a memory of the at leastone slave SOC, and to read data from the memory of the at least one SOC.21. The method of claim 14, wherein the bidirectional debug interface ofthe master SOC is a two pin debug interface including one pin for aclock signal and another pin for bidirectional data.
 22. The method ofclaim 21, wherein the bidirectional debug interface of the master SOCoperates in the non-default mode as the master bidirectional debuginterface by controlling a slave debug interface of the at least oneslave SOC, and wherein the clock signal is output from the master SOC tothe at least one slave SOC via the one pin for the clock signal.
 23. Themethod of claim 14, wherein the master SOC functions as a bus bridgebetween the external system and the shared bus.
 24. The method claim 14,wherein the external system accesses the at least one slave SOCindirectly through the master SOC.
 25. The method of claim 14, whereinthe master SOC includes a debug monitor.
 26. The method of claim 25,wherein the debug monitor performs a method comprising: analyzing arequest received by the user interface of the master SOC from theexternal system; scheduling transfer of the debug data over the sharedbus from the at least one slave SOC to the bidirectional debug interfaceof the master SOC; and transmitting the debug data received from the atleast one slave SOC via the user interface of the master SOC to theexternal system.
 27. The method claim 14, further comprising capturingtrace data from the at least one slave SOC by a trace buffer of themaster SOC, wherein the debug data comprises the trace data.
 28. Themethod of claim 14, further comprising the storing debug data in amemory of the master SOC.
 29. The method of claim 27, furthercomprising: transferring the trace data from the trace buffer via theuser interface of the master SOC to the external system; and analyzingthe trace data by the external system.
 30. The method of claim 14,further comprising transmitting the debug data by the bidirectionaldebug interface of the master SOC over the shared bus between the masterSOC and a plurality of slave SOCs.
 31. The method of claim 14, whereinthe debug data comprises trace data, debug control signals, and statusdata.